Subject: Reply to Jim Cobban on Migrating APPN to ATM

From: "Marcia Peters (8-444-4380)" <[email-masked]>
Date: Fri, 2 Jun 95 10:12:45 EDT

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Jim, IBM agrees with the majority of points in your May 9th note.  But
there are several areas where we are not sure what you are saying, or
we hold a different view.

o  We generally agree with your paragraphs 1-6:

   Yes, the limitations of LAN Emulation methods become vividly apparent
   with the arrival of ATM.  Yes, media that provide universal
   addressing and any-to-any connectivity can and should be modelled as
   connection networks.  We agree that address indirection is
   unattractive.

   PSTN *can* be a connection network, but has inherent difficulties, as
   you point out (and we know of others).  Single-port-per-user can be
   solved, at an unattractive cost.  In any case, IBM is not motivated
   to develop a PSTN connection network, at present.

   Not all the subnets you cite provide QoS (e.g. IP, CLNP), but that's
   not a key point, since our focus for new CNs should be new and
   emerging subnets, not old or fading ones.

o  We interpret your statements on ingress priority/delay scheduling
   slightly differently:

   We hear customers framing their needs in terms of requirements, not
   solutions.  For example, our customers require separation of batch
   and interactive traffic.  (This is an example, not an exhaustive
   requirement list.)  They desire to use lower-cost facilities for
   batch, or to limit the use of high-cost facilities to time-critical
   interactive and transactional traffic.  If facilities are shared
   among different traffic types, at times when the offered load exceeds
   the engineered network capacity, they want time-sensitive traffic to
   be delivered preferentially.  Traffic that is not time-critical has
   been designated as batch and can be delayed.

   In any event, there are several ways to accomplish this:

   -  Your suggestion is to implement layer 3 priorities in a
      multiplexed layer 2 service.  Actually, there is nothing to
      prevent a switch vendor from peeking into COS/TPF on an APPN BIND
      if you have some way to support this type of priority mechanism in
      your switches (but I doubt that how you customize your switches is
      a topic of COMMON interest to AIW members).

   -  We prefer a different model: we prefer giving the layer 3
      transport the option to set up multiple layer 2 VCs with
      appropriate traffic contracts (bandwidth) and QoS.  Then without
      customizing layer 2 for specific layer 3s, APPN (or any other
      intelligent layer-3 transport) performs mappings itself.  In this
      model, a subnet is strictly a service provider and APPN is a
      strictly a service consumer, according to a standard-specified
      interface (e.g., ATM Forum, ITU-T, ISO...)

      Actually, since tariffs and fixed equipment costs differ so vastly
      across geographies, we think it better to give customers a lot of
      flexibility in how they set up layer 2 services to meet layer 3
      requirements.  Where per-circuit charges are low, customers might
      want to provision (or dial up) several VCs with different QoS for
      APPN's use, with much granularity; where per-circuit costs are
      high, they might prefer having APPN mux all priorities onto a
      single circuit.

      To provide this flexibility requires some extensions to the LAN
      connection network model.  First off we MUST remove the
      restriction of one TG per port per CN.

      Please think of the LAN connection network model as a special case
      of a generalized connection network framework.  The generalized
      framework allows >1 TG/port/CN.  The ONLY reason for LAN CN's 1
      TG/port/CN restriction was because, ON A TOKEN RING, multiple
      connections have no advantage: the T/R MAC itself provides
      fairness to all users, despite single or multiple connections.
      The restriction makes no sense for FR, X.25, or ATM.

o  Our viewpoints appear to diverge further at paragraphs 9-10:

   While we agree on the desirability of minimizing TDU traffic and TDB
   size, zero change to the LAN CN model and to SS/TRS is not an absolute
   requirement.  In fact, we believe we have a way to meet the customer
   requirement articulated above without materially changing SS or TRS.

   We specifically disagree with your statement "It is desireable to
   leave <the question of mapping APPN priorities to one or more VCs> to
   the underlying network, rather than modelling it in APPN."

   Most SNA networks today are private networks that incorporate some
   public switched services.  Private networks BY DEFINITION are
   unwilling to rely solely on a single carrier.  A given APPN backbone
   node will usually have >1 link for availability reasons, and often
   the link types are different.  Thus your proposal to move VC
   selection to the DLC is unacceptable, since it would remove much of
   APPN's value.  DLC is not in a good position to select the route,
   since it can't know what other connectivity the node may have.

   Some form of passing signalling to and thru the DLC may be useful,
   but ONLY IF APPN CAN FIRST BE MADE TO PICK THE RIGHT ADAPTER AND
   LINK.  The existing RSS algorithm does this well, as long as the
   subnet is characterized in terms of TG characteristics.  That is,
   APPN needs a standard set of metrics to compare one TG with another.
   We believe the current TG characteristics are adequate for this since
   they are quantitative (e.g., actual propagation delay, capacity, cost
   per byte, etc.)

   What is deficient, however, are the current COS tables.  We noticed
   that the COS tables are oriented towards 1980s-vintage link speeds
   and error rates.  They lack sufficient granularity at high speeds.
   We think it would be a good idea to add some rows to the COS table to
   remedy this.  This is not urgent, but it would be good to do in the
   same time frame when products add native ATM CN support.

o  Finally, we agree APPN should not perform unnatural acts to
   accommodate weirdly-engineered CUGs.  For X.25, mapping each CUG to
   a different CN appears to be a good idea.

o  Signalling
   I have not yet reviewed this part of the proposal in detail.
   We'd like your reactions to the thoughts expressed above first.

o  In addition I'd like to respond to some concerns you raised verbally
   during the meeting:

   - One subject was how the APPN CP learns about transmission
     facilities that are available to it.  APPN architecture models this
     in terms of system definition of certain parameters to NOF.  You
     were concerned that the APPN CP not try to manage multiprotocol
     facilities of the whole node.  We agree.  Implementations will
     differ in where and how such parameters are obtained.  For example,
     a multiprotocol node might have a configuration utility to set up
     the whole node.  Whatever node resources are assigned to APPN could
     perhaps be passed to the APPN CP as NOF input parameters.  These
     are not architectural issues.

     What IS an architectural issue, however, is the need for all APPN
     nodes to use consistent metrics to express TG characteristics,
     especially effective capacity.  We need an architecture that says
     specifically how APPN capacity is set in the following cases:

       (1) reserved bandwidth,

       (2) best effort service

       (3) VC shared with other protocols:

            (3a) if the queuing system allows APPN to use all of
                 the VC's capacity when the other protocols are idle

            (3b) if the queuing system does not allow APPN to use all of
                 the VC's capacity when other protocols are idle.

     Consistent capacity reporting methods are needed, in order to meet
     customers' requirement for consistent behavior of APPN's route
     selection algorithm.

   - We didn't understand exactly what you meant about passing
     signalling to DLC.  By 'signalling' do you mean the information
     defined in, e.g., Q.2931?  Or does 'signalling' refer to parameters
     such as layer 3 priority information?  Did you mean at link
     establishment, or on each data packet?  One of us thought you
     proposed sysdef'ing setup parameters to DLC and then passing
     priority ON EACH PACKET; was that your intent?

   - Another person thought you wanted DLC to be able to establish
     multiple SVCs per link.  Was this your intent?

We'd appreciate clarification of these points and any others we may
have misunderstood.

Marcia Peters ......................... IBM Corp., APPN Architecture Team